A variety of improvements around tool parameter modeling (second try) #19027
+2,932
−693
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Was causing a randomly failing test.
2 tasks
bgruening
reviewed
Oct 18, 2024
| def static_validators(validator_models: List[AnyValidatorModel]) -> List[AnyValidatorModel]: | ||
| static_validators = [] | ||
| for validator_model in validator_models: | ||
| print(validator_model._static) |
There was a problem hiding this comment.
Suggested change
| print(validator_model._static) |
| self.datalist = [] | ||
| for title, value, _ in input_source.parse_static_options(): | ||
| self.datalist.append({"label": title, "value": value}) | ||
|
|
||
| # why does Integer and Float subclass this :_( |
| ): | ||
| super().__init__(message, negate) | ||
| assert filename | ||
| assert os.path.exists(filename), f"File {filename} specified by the 'filename' attribute not found" |
There was a problem hiding this comment.
Is that really needed here as assert?
| @@ -26,7 +26,7 @@ def stock_tool_sources(): | |||
|
|
|||
|
|
|||
| def _walk_directory_for_tools(path): | |||
| if path.is_file() and path.name.endswith(".xml"): | |||
| if path.is_file() and path.name.endswith(".xml") and "macros" not in path.name and "_conf.xml" not in path.name: | |||
There was a problem hiding this comment.
can you add a comment what you are trying here?
| self._inputs = inputs | ||
| return self | ||
|
|
||
| # aliases for self to create silly little English sentense... inputs.when.flat().when.legacy() |
| <inputs> | ||
| <param name="ref_parameter" type="data" ext="tabular" > | ||
| </param> | ||
| g <param name="parameter" type="drill_down" dynamic_options="collate_table(ref_parameter.dataset.get_file_name())"> |
There was a problem hiding this comment.
Suggested change
| g <param name="parameter" type="drill_down" dynamic_options="collate_table(ref_parameter.dataset.get_file_name())"> | |
| <param name="parameter" type="drill_down" dynamic_options="collate_table(ref_parameter.dataset.get_file_name())"> |
How could this pass tests?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A redo of #18952 on top of the new tool execution testing stuff and with a few more fixes.
Old PR Description:
This contains tests, fixes, and refactorings of the tool parameter models aimed at enabling two applications/APIs - these applications are a tool landing API and the tool request API. Those APIs and corresponding runtimes are not included here but can be found in the structured tool state branch (tool request API and tool landing API).
The bulk of the enhancements around enabling tool landing are found in a single commit titled "models for tool landing request state...". This introduces two new tool state representation types and wide variety of parameter specification tests that describe how the API will work and how models will be stored. The API will consume tool state with the representation type "landing_request" and will store the representation "landing_request_internal" in the database. The internal version is the decoded version of that tool state. The idea behind the landing API is that essentially everything is optional - external entities could for instance host a collection of FASTA files and provide links to tools to align against these for instance - all the parameters but the database would be deferred to the users discretion. The parameters that are provided though will be validated.
The remainder of the commits are a collection of things that make more confident were not doing damage with the tool request API. Part of that effort is having a fully expanded representation of the tool state that describes something pretty close to what we feed the wrappers - defaults expanded out, no absent conditionals, etc... That effort resulting in me writing lots of API tests to describe how the current API works so we don't regress it, implementing validation of static parameter validators so we can mimic some of the runtime behavior of the tools and write stronger upfront validation of the requests, etc...
How to test the changes?
(Select all options that apply)
License